home *** CD-ROM | disk | FTP | other *** search
/ Games of Daze / Infomagic - Games of Daze (Summer 1995) (Disc 1 of 2).iso / x2ftp / msdos / misc / doomproj / read.me < prev    next >
Encoding:
Text File  |  1994-12-15  |  5.2 KB  |  103 lines
  1. Doom is a registered trademark of id software.  I claim no affiliation
  2. with id.
  3.  
  4. Well, here is my first attempt at implementing the most basic
  5. concepts for a 3D type engine somewhere between Wolf3D and Doom.  I know
  6. it's not much, but I thought I would release it to the populace anyway.
  7. The astute person will realize that there is only one height for every
  8. wall, and the floors/ceilings are at constant height.  This is a limitation
  9. that allowed me some important optimizations when I was designing this
  10. program.  However, with what I have learned since (this program was 
  11. originally written for a graphics project (hence the name) as school last 
  12. spring), I think I could write a much more versatile engine that is just 
  13. as fast.
  14.  
  15. This program does its depth sorting using the by now all too famous
  16. BSP tree.  It uses a back-to-front traversal, as opposed to the front-
  17. to-back method Doom uses.  The reason for this is that I am not using
  18. mode X (as Doom does), and I think for simple levels like the one
  19. this engine is using, that keeping an off-screen buffer and just blasting
  20. that to the VGA is just as fast (and a hell of a lot easier :-).  This
  21. engine has the ability to render non-orthogonal walls, but constructing
  22. a BSP tree for a level containing such walls is not trivial, and I didn't
  23. want to spend the time implementing a BSP tree builder (which is also 
  24. non-trivial) for this first attempt.
  25.  
  26. The entire program is written in C and compiled with Watcom 9.5.  My
  27. personal belief is that VERY little would be gained by converting any
  28. of this code to assembly as the Watcom compiler is VERY good at code
  29. optimization.  I spent a little time researching its optimization methods
  30. and attempted to write the t-mapping routines to lend themselves well to
  31. its optimization methods (read: they are unrolled already).  The code is
  32. fairly portable.  I was able to port it to X (with MIT-SHM, BTW) in about 
  33. 5 hours.  I have compiled and ran this X port on all sorts of UNIX machines
  34. ranging from LINUX boxes to HP Geckos with interesting results.
  35.  
  36. I actually wrote my own clipping algorithm.  I don't clip in screen space
  37. since that can create interesting resultant geometric shapes; rather,
  38. I used a method that I figured out (which maybe someone else did too)
  39. involving parametric lines.  This clipping proves to be pretty fast, but
  40. it has a problem.  In the clipping process, there is a divide which has
  41. a fixed-point representation in the denominator.  This SEVERELY limits
  42. the accuracy of the fixed-point representation since you have to use some
  43. amount of your precision to represent that number.  Therefore, you will
  44. see that walls don't extend exactly to the edge of the screen sometimes.
  45. I have identified this problem and will fix it in my next attempt.
  46.  
  47. I currently use a 486DX2-80 CPU and get ~45 fps.  With my old 486-66, I
  48. would get ~35 fps.  I think this is pretty good considering the floors
  49. and ceilings are texture-mapped (and the region to map on these surfaces
  50. was not selected very intelligently).  I would be interested in hearing
  51. from people about which type of machine they have, and what performance
  52. they saw.  I have ran this on machines as slow as a 386-25.  While the
  53. frame rate was sorry, I didn't witness any tearing, flickering, or any
  54. of those undesirables.
  55.  
  56. I did do collision detection with the walls (you can't walk through them),
  57. however, if you can't go the direction you want to go because a wall is in
  58. your way, the program just negates your move.  This means if you are 
  59. looking at a wall with a very oblique angle, and pushing the up arrow
  60. key, you will not move forward (as you will in Doom).
  61.  
  62. There are many bugs, including: improper forshortening in the texture
  63. mapping, erratic clipping errors, distorted texture-mapping at close
  64. range, occaisional crashes, however, I think it is pretty stable at this
  65. point.  That is why I am releasing it.  At this point, I think I will
  66. start over and apply some of the new concepts I have learned.  I also have
  67. an idea for texture-mapping that may prove to be a huge optimization, I'll
  68. let you know.
  69.  
  70.  
  71. USE:
  72.  
  73. type "proj" at the command line.  The keys are:
  74.  
  75.   up arrow    : move forward
  76.   down arrow  : move backward
  77.   left arrow  : turn left
  78.   right arrow : turn right
  79.  
  80.   escape      : quit
  81.  
  82. The forward/backward keys are buffered so you get a smooth transition from
  83. stopped to full speed.  Try it, you'll see what I mean.  The turn keys
  84. are not buffered in this way.  It didn't seem too realistic to me.
  85.  
  86. I implemented a crude replay mechanism.  While you are moving around
  87. my level, your moves are recorded and placed in a file called "shadow.fil".
  88. If you start this demo with the '-r' parameter (ie: "proj -r"), it will
  89. replay the moves that were made the last time the program was run.  There
  90. is no way to stop it from recording when you execute, so if you want to
  91. save a series of moves, rename the "shadow.fil" file before you run the
  92. program.
  93.  
  94. From here I plan to write a more advanced engine that will read Doom wad
  95. files and basically display them in exactly the way that Doom does.  I 
  96. am hoping I can get my program to at least the efficiency that Doom is at.
  97.  
  98. Well, anyway, here it is.  Please drop me a line and let me know what you 
  99. think.
  100.  
  101.  
  102.  
  103.